1. Field of the Invention
The present invention relates to logic analyzers for analyzing program execution in computer systems. More specifically, the present invention relates to a method and apparatus for embedding commands within a computer program that change a criterion for storing data in a logic analyzer.
2. Related Art
Logic analyzers are commonly used by computer system developers to debug computer hardware and software. Logic analyzers operate by periodically capturing the state on a set of signal lines in a digital system, such as a computer, with reference to a time base, such as a system clock. A logic analyzer typically "triggers" when it encounters a pre-selected pattern on the set of signal lines. Triggering causes the logic analyzer to take a snapshot of a set of data patterns immediately preceding and/or following the particular pattern--or trigger point. This allows a developer to view events surrounding the trigger point.
One problem with using logic analyzers is that they commonly record large volumes of data, which can be cumbersome to store and manipulate. Because a logic analyzer typically contains a limited amount of memory for storage, recording a significant volume of data from the execution stream of a computer program can quickly overrun the logic analyzer's internal storage capacity. This is especially true for logic analyzers that are embedded within computer systems for fault-tolerance purposes. Such embedded logic analyzers tend to be small and inexpensive. Hence, they typically include a limited amount of memory for storage of data.
Even if a logic state analyzer can successfully record a large volume of data into a large file, the task of manipulating the large file to analyze the data can be a slow and cumbersome process. Simply reading the large file from disk, and possibly sending it across a computer network, can take many minutes, and possibly hours. Furthermore, analyzing the large volume of data can consume a large amount of processor time.
Fortunately, much of the data recorded by a logic analyzer is not relevant in diagnosing a system error. Programs typically execute many repetitive loops that perform simple tasks, such as initializing an array. Function calls and returns require a tremendous number of instructions to save and restore state and to pass parameters.
In order to remove some of this irrelevant data, some logic analyzers provide qualifiers that can be used to filter input data patterns. For example, a qualifier might specify that only write operations are to be recorded. Some logic analyzers can be programmed to change these qualifiers upon the occurrence of certain input patterns.
Using qualifiers can somewhat reduce the number of input patterns recorded by a logic state analyzer. However, a developer programming a logic analyzer to gather data typically has limited insight into how to filter out irrelevant data. A programmer actually viewing the code before it is executed typically has more insight into which portions of the code are likely to create important input patterns. Hence, it is desirable to give the application programmer some measure of control over what types of qualifiers or trigger conditions are to be used to gather data from certain portions of code.
Such control over the internal operation of a logic analyzer is presently not possible from within existing programming languages. Sometimes programmers augment code to embed a special trigger command in a program. When the trigger command is executed, it causes the logic analyzer to take a snapshot of the input data stream. Programmers have also augmented code with commands that embed "markers" into the data stream generated by the program. A marker command typically causes a write to a specific I/O locations, which creates an easily identifiable input pattern for the logic analyzer. Thus, a programmer can insert marker commands into a program to identify specific program locations, such as the start and the end of an interesting piece of code.
Unfortunately, none the above-mentioned programming language features allow a programmer to explicitly control what type of data is gathered, and what trigger conditions are used in different sections of code.